A Wi-Fi client device, for example, as defined by IEEE 802.11, goes through a setup process to associate/connect with a Wi-Fi Access Point (AP). The setup process typically includes the client device scanning for AP's within range, displaying AP's found within range of the client device on a display interface, receiving user selection of a displayed AP via an input interface, receiving/transmitting a network key or password (typically required by the AP) entered by the user via the input interface, and establishing a connection to the AP. If the network key is incorrect, an error message is displayed to the user.
The Internet of Things (IoT) describes a wide range of emerging consumer devices that require network integration as part of their underlying functionality. For most such devices they must connect to a network, and the normal use case involves connecting to a local network AP.
Many IoT devices will feature at least a rudimentary user interface (UI) comprising either a touch-screen; or keypad and screen, enabling a password to be entered to establish a secure wireless link with the local network. Additional device configuration may then be effected via the same user interface, including establishing a link to a local IoT supervisor or to a remote IoT server. Again, user entry of passwords and keycodes is prone to error and may be unacceptable to many consumers.
At the same time, some limited-UI IoT devices, for example, web-cameras, security lights or sensors may lack one or both of an input interface and display interface and so do not readily provide a suitable user interface for such configuration.
Current attempts to simplify Wi-Fi setup, such as Wi-Fi Protected Setup (WPS), either require PIN to be entered, or pressing buttons on the client device and AP at the same time, or both, while others send information to the client device without encryption, exposing the Wi-Fi network to snooping devices. Some IoT devices such as a simplicam web-camera from ArcSoft obtain required configuration information for connecting to a local AP using out-of-band channels, such as by imaging a QR code provided by an authorised user's smartphone; while others such as the HeeLight smart bulb obtain their control information through a coded/modulated sound burst provided by an authorised user's smartphone
However, it is not alone sufficient for today's IoT devices to join a local network, they may also need to join some form of network service or, as becomes more common, an external Internet or Cloud service. There has been significant growth in such services to manage local network devices such as those in the home. Thus, once they are connected to the local network, individual devices need to access external URLs on the Internet via their local AP.
Cyber-security is key for success of IoT. Consumers are already concerned with the security of their devices and major vendors have moved to securely encrypt all major device communication from mobile devices. Thus integrated e-mail services such as gmail and iOS-mail now provide end-to-end secured communications including providing two-factor authentication.
Some manufacturers even provide an integrated security keychain across all of a consumer's registered devices. Thus, a user knows if a new device is added or rejoins their private cluster of devices. It is also possible, for this group of secured devices, to enable the sharing of services, content and application functionality within a group of users. This approach, known commercially as family sharing, is useful as it allows shared access to services, but also allows granularity at both the user and device levels.
To ensure robust security and centralized authentication and service control, these services are cloud based and are typically linked to a payment mechanism such as a credit card. Such services will hereafter be referred to as Key-chained Cloud Services (KCS). Today, these offer best practice in consumer security for mobile device services.
The challenge for IoT devices, is that each device is vulnerable until it becomes configured. Even if it will eventually establish a secure, encrypted communication with the cloud service, the initial configuration steps can be typically unsecured, as can the initial establishing of a TCP/IP link with the local network access point.
WO2014/163877 teaches shifting the network setup functionality from a limited-UI device to a full-feature device. At first power up, when a reset button is pressed, or whenever the limited-UI client device cannot connect to the network, the limited-UI device enters a network setup mode that allows a full-feature device to connect to the limited-UI device. For example, if the network is Wi-Fi, the limited-UI device becomes an AP for the full-feature device or the limited-UI device goes into Ad-Hoc mode.
WO2014/131038 teaches enabling communication among one or more IoT device groups. In particular, various heterogeneous IoT devices that may need to interact with one another in different ways may be organized into IoT device groups to support efficient interaction among the IoT devices.
WO2014/131029 teaches enabling context aware actions among heterogeneous IoT devices including receiving, at an IoT device, data representing a context of each of a first set of IoT devices in an IoT network, receiving, at the IoT device, data representing a current state of each of a second set of IoT devices in the IoT network, and determining, by the IoT device, an action to perform at a target IoT based on the received data representing the context of each of the first set of IoT devices and the received data representing the current state of each of the second set of IoT devices.
WO2014/131035 teaches controlling of IoT devices based on detecting a device and obtaining control information and associated rules for controlling the device. The control functions available to a smart controller can vary based on the condition of the various rules and/or the interaction of the various devices detected.
WO2014/131015 teaches collaborative intelligence and decision making in an IoT device group. In particular, various IoT devices in the group may be interdependent, whereby a decision that one IoT device plans may impact other IoT devices in the group. Accordingly, in response to an IoT device planning a certain decision (e.g., to transition state or initiate another action), the IoT devices in the group may collaborate using distributed intelligence prior to taking action on the planned decision. For example, a recommendation request message may be sent to other IoT devices in the group, which may then analyze relationships within the IoT device group to assess potential impacts associated with the planned decision and respond to approve or disapprove the planned decision. Based on the responses received from the other IoT devices, the IoT device may then appropriately determine whether to take action on the planned decision.
WO2014/131001 teaches determining an association among IoT devices includes receiving, at a first IoT device, an identifier of a second IoT device, obtaining, by the first IoT device, a schema of the second IoT device based on the identifier of the second IoT device, and determining, by the first IoT device, whether or not there is an association between the first IoT device and the second IoT device based on a schema of the first IoT device and the schema of the second IoT device, wherein the schema of the first IoT device comprises schema elements and corresponding values of the first IoT device and the schema of the second IoT device comprises schema elements and corresponding values of the second IoT device.
WO2015/017268 teaches establishing a connection between first and second IoT devices. After a determination is made to execute a proximity detection procedure, the second IoT device outputs an audio emission and a data packet at substantially the same time. The first IoT device detects the audio emission via a microphone and receives the data packet. The first IoT device uses correlation information to correlate the detected audio emission with the data packet, whereby the correlation information is contained in the detected audio emission, the data packet or both. The first IoT device uses the correlation between the detected audio emission and the data packet to calculate a distance estimate between the first and second IoT devices.
Referring to FIG. 1, WO2014/031542 teaches configuring a new enrollee device (140) for a communication network (120) including a network node (230) where an electronic device (110) obtains (250) a device password associated with the new enrollee device. The device password is provided (154) to a network registrar (130) to cause the network registrar to configure the new enrollee device for the communication network. The network registrar performs an enrollment process (226) based upon the device password and, optionally, provides feedback (160) to the electronic device to indicate whether or not the new enrollee device was successfully enrolled (i.e. added) to the communication network.